Subject: Flow Control Proposal ( again - YAFCP)

From: "Shannon Nix" <[email-masked]>
Date: Mon, 06 Jun 94 14:53:09

Sorry,  I've been trying to send this for a week.  Hopefully the 
          recently remedied "email problem" was the culprit.
          
          Hi all,
          
          There has been considerable discussion about the modified flow 
          control proposal and its propensity to display 
          definite-response-mode-like attributes in certain situations.  I 
          have a proposal which I believe will remedy that.
          
          Let me first characterize the differences between the modified 
          proposal and the original proposal.
          
          1.  In the modified proposal, the window granted in a PRSP         
              replaces any residual window left over from the previous 
              grant.
          
          2.  In the original proposal, there was an implicit grant of the
              initial window size when the circuits were established.  The 
              modified proposal required an explicit grant from the          
              receiver.
          
          Now in both proposals, the sender shall send the PREQ for the next 
          window on the first frame of a new window.  However, in the 
          modified proposal, this attribute combined with rule (1) implied 
          that the sender would always send a PREQ on the next frame after 
          receiving a PRSP. 
          
          As I mentioned to Bill Kwan, in a response to one of his earlier 
          mailings, it has occurred to me that the side effect mentioned in 
          my previous paragraph was the key element of the proposal, NOT the 
          fact that the previous window was replaced!
          
          So, having considered this for a while, I believe that the 
          modified proposal should differ from the original proposal by the 
          following two points instead:
          
          1.  The sender request a new window using PREQ on the next frame a 
              after receiving a PRSP.
          
              NOTE:  PRSP grants remain cumulative.
              NOTE:  The receiver is not compelled to, and likely won't, 
                     return PRSP immediately upon receiving a PREQ.
          
          2.  Same as the above modified proposal.
          
          POSSIBLE FURTHER EVOLUTION TO THE PROPOSAL.
          
          I would also like to throw out one other possible incremental 
          change that I believe would add value to the proposal:
          
          RWI and HWI are rather crude mechanisms to respond to congestion 
          conditions.  I would like to borrow an element from Derek Bolton's 
          (Metaplex) proposal to replace these:
          
          1.  The receiver can send a message: CUTBACKTO(x) which carries an 
              explicit value which, when received defines the exact number 
              frames which the sender may now send.
          
          2.  If this is less than the number previously granted but not 
              consumed, then the sender should send a REFUND(y) message to 
              "sweep" and allow the receiver to cutback his commitment.  
          
          3.  The receiver may only have one CUTBACKTO(x) pending at any     
              time.
          
          This provides more flexibility the RWI and HWI.  
          
          SOAPBOX:
          
          I really believe that we should also use explicit values for the 
          PRSP message on grants as well (ie: do away with xWI altogether an 
          just tell the poor sender how many frames you are granting him). 
          Unfortunately, IBM believe that they have patented the concept of 
          a receiver in a protocol explicitly indicating to a sender how 
          much data he is willing to receive (someone should notify the TCP 
          folks).  Of course, use of other operators to adjust the window 
          grant size(++, --, /2) are acceptable as long as we don't use the 
          assignment operator ( =x) ????
          
          Regards, Shannon

---

From: Bill Kwan <@uunet.uu.net:[email-masked]>
Date: Mon, 06 Jun 94 20:10:19 EST

Shannon,
     
     I don't think just changing the pacing back to cumulative by itself 
     will solve the problem. Like you, I also got side-tracked on the
     cumulative issue. After more careful analysis, I see two
     necessary aspects that keep traditional SNA pacing from degrading 
     into "Definite-Rsp-Mode-Like (DRML)" mode. One is the cumulative 
     aspect and the other is (more importantly) WHEN a pacing request is 
     sent (when Pacing Count is equal to Next Window Size, i.e., beginning 
     of next window). The assumption is that in the best steady state (no 
     congestion), the receiver will send a pacing response back right away 
     (simpliest implementation). The cumulative aspect forces one pacing 
     request to be sent per pacing window (thereby spacing them out far 
     enough to not degenerate into DRML mode). Since your proposal forces 
     the Pacing Request to be sent immediately after receipt of the Pacing 
     Rsp (the key to the feedback mechanism), the importance of cumulative 
     pacing has been eliminated. The burden is now on the pacing receiver 
     to know when to send the Pacing Rsp to prevent DRML. Another word, we 
     are still going to need some algorithm on the receiver like the one 
     that Paul proposed (e.g., half the window) to ensure that we don't go 
     into DRML mode. 
     
     We were (at least I was) focusing on the wrong cause of the problem. 
     It is not the cumulative issue that is the problem but rather the 
     fact that the pacing request has to be sent immediately after receipt 
     of the pacing response. So, making the pacing cumulative is not going 
     to change anything (except may be Paul's heuristics ?).
     
     I think either scheme (with Paul's addition) can still work 
     (cumulative may even make it more complex on the receiver), but I 
     think we need to add one more bit of information in the spec.
     After looking at Paul's flows and got real confused at when the NWS 
     should be incremented (it turned out he didn't show such a case), I 
     realized that it would be useful if we specify how the receiver could 
     use this feedback. For example, keep track of previous window size 
     and check if all of the window was used when the PREQ is received (a 
     little more complex if the pacing is culmulative - i.e., keep track 
     of the previous 2 window sizes? ). An implementer could, of course, 
     ignore this if he wants to, but at least he would know what should be 
     done.

SOAPBOX:
     
     If I may get on your soapbox (hope it doesn't break). Like you, I 
     think the best solution to these two problems have been already 
     solved by IBM. For the sender feedback problem, I feel that tying the
     feedback with the PREQ causes unnecessary complexity at the receiver 
     that could easily be handled at the sender. I have not look at the
     exact wording of the RLWI aspects of the patent, but I wonder if we 
     have looked at any "loopholes". Off the top of my head, some wild 
     ideas like:
     
        1) renaming the bit to mean Last Window Was Completely Used.
        2) reverse the meaning of the bit
        3) Sending the indication on the next data (instead of
                piggybacking on the next PREQ), if that was the issue
     
     I am sure there are others when one more carefully study the wording 
     of the patent. Of course, IBM could also re-consider it's position on 
     the patent :-).
     
     Comments?

     Regards,
     
     Bill
     [email-masked]

______________________________ Reply Separator _________________________________
Subject: Flow Control Proposal ( again - YAFCP)
Author:  [email-masked] at inet
Date:    6/6/94 2:53 PM

          Hi all,

     

     

     

     

     

     
          SOAPBOX:

          Regards, Shannon